CPU Cache Overview

To improve performance some CPU's of the 68k family are able to cache memory accesses.
Caches are always refered using logical addresses, including the function code of the access. That means e.g. that access in Usermode and Supervisor will create different Cache entries.

Cache managment in WHDLoad

 The first important thing is to understand that the caches on 68030..68060 are controlled by the Cache Control Register (CACR) and the MMU (assumed WHDLoad uses and controls the MMU)!
In the CACR the caches will be global enabled or disabled. Using the MMU single Pages (4 KByte with WHDLoad) will be marked how they can be cached.
On the 68030 a memory page can be Cacheable or NotCacheable. On a 68040/68060 it can be cachable WriteThrough, cachable CopyBack, NonCachable (impercise) or NonCachable Serialized (precise).

Default Cache Setup

By default the areas of WHDLoad, the Slave and ExpMem are marked as cacheable CopyBack. The BaseMem area is marked as NonCachable, and the Data and Instruction Cache are enabled in the CACR. So the program located in the BaseMem area runs without Caches but WHDLoad and the Slave use the Caches for best performance.
If the MMU is not used by WHDLoad, it controls only the CACR.

Programmers Cache Control

There are two resload functions to control the Caches, resload_SetCACR and resload_SetCPU. resload_SetCACR is the historical older routine and can fully replaced by resload_SetCPU (WHDLoad internal maps the arguments of resload_SetCACR and calls resload_SetCPU). Anyway the usage of resload_SetCACR is recommend for all people which do not know all about Caches and their behavior in a Amiga system. Using resload_SetCACR the instruction and data cache can seperately enabled or disabled. resload_SetCACR does only affect the cacheability of the BaseMem area.

User Cache Control

If the programmer has done a clear job then the user has nothing to do regarding the Caches because all required setup is already done by the Slave.
Nevertheless there may be two reasons for changing manuelly the Cache setup. First to make a install working which has problems because it runs to fast (e.g. creates graphics errors) and second to make a installed program faster.

To make a crashing program work the option NoCache can be used. This option disables all caches and marks all memory as NonCachable Serialized (precise). If the machine has 32-bit Chip-Memory it will be still faster than a original then a plain A500.

To make a installed program faster some options can be set which enable Caches. That will overwrite the setup by the Slave. On the 68020 the option Cache can be set. On 68030 also the option DCache can be used which includes option Cache too. On the 68060 there are some more options: BranchCache, StoreBuffer and SuperScalar. The option NoChipCache/S can improve the performance on 68040 and 68060, see below.

Cachebility of Chip-Memory

The cachebility can not only set by the CPU itself (CACR) and the MMU setup but also by external hardware. The CPU is signaling on the bus if it tries to cache a access. Also an external hardware can signal the CPU (after an address has been put on the address bus during an memory access) that an access must not be cached.
The mechanism that hardware signals the CPU that memory is not cacheable is used on all (I think at least) Amigas and CPU-Boards with CPU's >= 68030 (because they have a data cache). Affected is the whole Chip-Memory and IO-Space (Cia/Custom/RTC) which must not be cached by the data cache. This is neccessary to avoid cache inconsistenies, for example because DMA activity.
The reaction of the CPU on a hardware reject of a cacheable access varies on the different CPU's. On the 68030 there is no impact on performance of the access, the data will simply not cached. On the 68040 read accesses will performed in full speed but write accesses (CopyBack) will be canceled and restarted without cachebility which results in around 5 times (depends on hardware and CPU speed) slower access compared to an noncacheable access. On the 68060 read and write accesses will be canceled and restarted. Read accesses will be around 3 times slower and write accesses around 5 times.
The mentioned issues are related to data accesses. Instruction accesses are usually not affected and also cacheable inside the Chip-Memory. There is some (maybe broken) hardware which does not allow instructions to be cached in Chip-Memory. On such hardware the option NoChipCache/S should be used to avoid a major slowdown in the execution speed because elsewhere instruction accesses will be around 2 times slower.

You can check this behavoir on your machine by executing the speed.slave contained in the src/memory-speed directory of the developer archive.

Write Allocation

The Write Allocation controls the cache handling on the 68030 when a cache miss occurs on a write operation. Write Allocation must be enabled when parts of the installed program are running is User Mode. If the installed program runs only in Supervisor mode Write Alloction can be disabled, which may give a minimal performance advantage.

Branch Cache

The Branch Cache is only available in the 68060. It is a kind of instruction cache for branch instructions. But in difference to the instruction cache it is not affected by the MMU setup! That means even when the appropriate memory Page is marked as Non Cacheable, branch instructions will be cached if the Branch Cache is enabled.

Read the Motorola Microprocessors User Manuals for further informations. If you have corrections or additions to this page please contact me.